The ability to access information over a network has been a boon to most users. That a user can access desired information from a remote location (possibly, even a location that the user could not locate or reach physically) has resulted in benefits to many.
But it remains important to be certain that the user accessing the resource is a legitimate user. To that end, users need to log in to the network and authenticate themselves. If they cannot identify themselves properly to the network, they are denied access to the network resources. This situation occurs when the Common Internet File System (CIFS) authentication is used, and is exemplified in the Novell Network Attached Software Appliance and Novell Branch Office products.
Originally, the server that performed authentication was the server that stored the resources of interest to the user. This situation is exemplified by FIG. 1. The user operates client or user workstation 105. Client 105 can be any type of computer system: desktop, laptop, thin client, dumb terminal, personal digital assistant (PDA), etc. Client 105 includes the appropriate components for its design. For example, if client 105 is a desktop computer, client 105 includes computer 110, monitor 115, keyboard 120, and mouse 125, as shown. The computer includes a central processing unit, memory, and other appropriate elements. Other components of client 105 can be present, such as a printer. A person skilled in the art will recognize other variations of client 105.
Client 105 computes a hash of the user's password, by applying a hashing algorithm to the password. By hashing the user password, there is no concern that the user's password might be sent “in the clear,” where it might be intercepted. Client 105 then contacts server 130 across network 135. Network 135 can be any variety of network connection between client 105 and server 130. For example, network 135 can be a direct connection between client 105 and server 130, a wired network connection (such as Ethernet or token ring), a wireless connection (such as IEEE 802.11b, IEEE 802.11a, or Bluetooth), or any other type of connection. Client computer system 105 provides the user's name and the hashed password to server 130. Server 130 looks up the user's name in user list 140 to determine the user's cleartext password. Server 130 then uses a hashing algorithm (such as hashing algorithms 145, 150, or 155) to hash the cleartext password. (Which hashing algorithm is used depends on 105 client computer system, as different computers could use different algorithms.) Server 130 then compares the hashed passwords. If they match, the user is authenticated, and is then granted access to resources, such as resource 160.
One variation of this approach separates the responsibility for authentication from the responsibility for storing the resources. This situation is exemplified in FIG. 2. In FIG. 2, the user contacts application server 130 from client 105. But rather than having application server 130 be responsible for authenticating the user, application server 130 instead passes the responsibility for authenticating the user to an authentication server, such as one of authentication servers 205, 210, or 215. (Application server typically selects the appropriate authentication server to contact based on the resource the user is attempting to access.) Using authentication server 205 as an example, the authentication server includes user list 220 and implementations of hashing algorithms 225, 230, and 235 (which correspond to the implementations of hashing algorithms 145, 150, and 155 of FIG. 1). Authentication servers 210 and 215 are configured similarly. Authentication server 205 looks up the user's cleartext password based on the user's name, hashes it, and compares the hashed passwords to authenticate the user. Authentication server 205 then returns the result to application server 130, which then grants or denies the user access to resource 160, depending on whether the authentication succeeded or not.
While moving authentication away from the application server has its advantages, in that it compartmentalizes responsibility, it has drawbacks. One drawback is that if authentication server 205 is unavailable, application server 130 cannot grant the user access to the resources, even if application server 130 is available. Techniques to address this problem are described in related U.S. patent application Ser. No. 10/061,911, titled “Authentication Cache in a Distributed Network Environment,” filed Feb. 1, 2002, and to U.S. patent application Ser. No. 10/061,895, titled “Authentication on Demand in a Distributed Network Environment,” filed Feb. 1, 2002.
Another problem is that each authentication server has to know all the possible hashing algorithms that might be used by the client. If a new client becomes available that uses a new hashing algorithm, that hashing algorithm has to be implemented and installed in each of the authentication servers 205, 210, and 215. This has to be done manually: there is no mechanism for automating the development of the hashing algorithm. And it is usually not possible to implement the hashing algorithm only once and install it in each authentication server: Each authentication server typically has a distinct hardware/software environment, requiring specialized effort to implement the hashing algorithm in the environments. As the number of different hashing algorithms grows, it becomes increasingly complex to ensure that each authentication server has a proper implementation of each hashing algorithm: the number of implementations increases exponentially.
Accordingly, a need remains for a way to perform authentication using an authentication server, yet avoiding the exponential complexity in implementing hashing algorithms for each authentication server, to address these and other problems associated with the prior art.